In creating documents on a computer, there are tasks that are performed over and over again. In such cases, it is desirable to automate the creation of repeated tasks in order to save time. One such way of saving time is using a tool to create the repeated portions of the document.
For example, in Visual Studio 6 by Microsoft, a programmer can define a class method by using a dialog called a Wizard. When a programmer provides information about a method (e.g., name, parameters, return type, visibility), the method declaration is output to a header file and an empty method body with a “TODO” comment is output to another file. Then a programmer implements the method body by writing code in place of the “TODO” comments. However, if a programmer determines that changes need to be made to the method parameters, the programmer would like to use the Wizard to make the changes while preserving the code already written in the method body. However, Visual Studio 6 does not allow it. It only allows the creation of new methods and deletion of existing methods.
Another example is a Test Modeling Toolkit (TMT), by Microsoft, which is a testing tool. TMT allows the generation of general test cases in the form of test models. Once a model is defined, TMT can generate files in a language of choice (C++, C# or script languages) which can be used later to run test cases for the test model. The generated test files must be edited to enable sensible tests.
FIG. 1 is an example of a conventional tool that saves time in document creation. A tool 102 is a program that receives a tool input 104, and outputs a tool generated document 106. The tool input may be from templates, files, or other input resources. Often, the tool input includes content that is reused, so time is saved during document creation. The tool generated document 106 may include content from the tool input 104, along with other content as configured by the tool 102, based on user 112 input to the tool through a user interface (e.g., a graphical user interface, or GUI). A few examples of such conventional tools are wizards for developing or testing computer programs, and wizards for creating text documents, spreadsheet documents, or presentation documents.
Since the tool automates portions of the document, other portions of the document may require additional content or changes. Using an editor 108, and the tool created document as input 106, a user 112 creates an edited document 110. The editor 108 may be part of the tool 102, or may be a separate program.
FIG. 2 is an example of a tool input 202, a tool generated document 204, and an edited document 206 showing a conventional scenario of content progression. In the conventional scenario, a tool allows the user to automate content selection, arrangement, and configuration (i.e., configuration), thereby creating a tool generated document containing tool configured content 204 (i.e., a base document). From this base document 204, a user 112 (using the editor 108) edits and/or adds content to the base document 106 to create an edited document 206.
For example, given the context of the document being generated as configured by a tool user, there is much content that the tool knows how to configure and generate. For example, a tool that automates writing business letters generates content from a template such as a company letterhead and logo. Content may also be selected for the letter body (repeat forms or paragraphs selectable from a template(s) by a user using a tool menu or GUI). The tool generates other content such as the date or addressee. In another example, the tool is a program developer's tool, and from a selected language type (e.g., C++, Pascal) the tool generates a file, a file header, or many files that are required to compile a program. For example, a generated content such as a program header may contain references to class libraries which support the program. The tool may also generate a number of method signatures in order to define input-output parameters for identifying and controlling program module interactions. This process creates a boilerplate of code which includes sections that are filled-in by a user, such as the code within the method body. In the case of automated program development, or automated test code generation, a tool input also includes information that is of no real user interest, but is required to make the program or code usable by the computer. The uses for such conventional tools are diverse and well known.
FIG. 3 is a simplified pseudo-code example of a one-way-trip for content progression for a conventional tool generating test cases for testing a program. In one such conventional example, a user 112 is a program tester, who is generating code to test a program. In this example, using a GUI associated with the tool 102, a user 112 configures a document 306 to be C++ source code for testing the results of a buffer overrun, and then adds code to the test body to create an edited document 312. So the resulting code 110 is a test case for testing a computer program. In this example, based on the C++ source code configuration by the user, the tool 102 inserts header information from a tool input 302 into a tool generated document 306.
Further, a user may select content 304 used for testing, or content 304 may be forced by the tool input 302 or tool, into the tool generated document 306 as shown 308. In this example, a test method called “TestBuffer( )” 304 is inserted into the tool generated document 306. In this case, the tool 102, with the possible help from a user 112 through a tool GUI, configures the TestBuffer 302 parameter to include a string 310 parameter. In this one-way-trip example, after the tool generated document is complete 306, a test developer 112 uses the editor 108, to create an edited document 312. In this case, the test developer adds test code for overloading a buffer and writing any error code to a test file 314. In this conventional one-way-trip example, once the tool generated document is created 306 and edited 108 by the user 112 to create an edited document 312, the process is complete. A test developer then compiles the document 312, and runs the test case(s).
As shown in FIG. 4, using this conventional one-way-trip process, if the tool or the tool input adds content or configures content, a problem occurs. In this case, a tool input 406 adds and requires a new method called “GetBufferSize( )” 402, and the tool adds a parameter to this new method 404. The problem occurs because the tool input has no knowledge of the pseudo-code 314 added by the user in the previous iteration 312. Using this one-way-trip process, the tool and tool input are unable to incorporate prior work done by the user with the editor 314, 108. Thus, in this conventional system, a user would manually cut and paste the content 314 from the previously edited document 312 into the new document 408 as shown 410. In some cases, several iterations of changed tool input's and tool configuration's require a user 112 to use the editor 108, to cut and paste additions or edits into each new generation 408 before desired testing was complete.
As shown in FIG. 5, a conventional round-trip-user-tag method was developed to eliminate redundant user cutting and pasting. The conventional round-trip-user-tag method works the same as the one-way-trip model, with two additions. First, the tool input 502 inserts user tags into the tool generated document 506. The user tags indicate where users are able to edit the document 508. Second, when the tool 504 or the tool input 502 was later changed thus requiring regeneration as previously discussed, the edited document with user tags 508, served as input to the tool 510. Thus, when changes were made to the tool or tool input, thereby requiring regeneration, those changes would serve as input to the tool and used to create next generation tool generated document 506. However, the content added by the user within the user tags in the previous iteration 508, was also fed back into the tool as input, and inserted in the next generation tool generated document 506. This created a way that the tool would cut and paste content from prior user edits, so it no longer had to be done manually as previously discussed.
As shown in FIG. 6, under the conventional round-trip-user-tag method, a tool input 602, or a tool 504 would contain content 606, 604, that controlled where within the content a user could edit the content. Once the tool generated document with user tags 506, 608 was created, a user could use the editor 512 to create an edited document with user tags 508, 610. In this example, the user adds content between unique tags 612, 614 which are identifiable in the tool input in a one-to-one relationship. The benefit of this conventional round-trip-user-tag with one-to-one correspondence with the tool input, is that when the user edited document is later received as input to the tool during regeneration 510, the tool knows where user edited content needed to be pasted into the next generation tool generated document with user tags 506. This conventional round-trip-user-tag adaptation of the one-way-trip method saved time because users were no longer required to cut and paste prior edits into the next generation. Although round-tripping with user tags is an improvement over one way generation with cut-and-paste, significant limitations became apparent.
For example, edits made by a user outside the user-tags were ignored by the tool and lost in regeneration. Further, the tool and tool input introduced significantly more user-tags (and clutter) into the base document than were used in the edited document. No matter how many tags were added to the tool input, there are always edits that a user can make outside of the tags's scopes. These changes would be ignored by the tool during regeneration. So the method was both over-inclusive and under-inclusive.
As shown in FIG. 7, a tool generated document with user tags 702 is shown with an example edited document content 704 that that will be ignored during a regeneration 510. If content is inside the tags 706, 708, it is carried to a next generation, if it is not inside the tags 704 it is ignored by the tool during regeneration. In this example, a user has attempted to make a class “TestBuffer( )” 710 inherit from another class called “BufferClass” 704. This user's edits 704 were ignored during regeneration 5 10.
The problem with this conventional roundtrip-user-tag solution is that a decision needs to be made in advance about what content can be edited or added by the user, and what content is controlled by the tool. If content is within the user-tags, it is controlled by the user, otherwise, it is controlled by the tool. This creates content conflicts that can not be resolved. For example, when an inheritance descriptor is outside the user tags, changes made by the user to the inheritance class are ignored under this conventional model. This required the user to go back into the regenerated document, and manually change the inheritance each time the document was regenerated. Further, if the inheritance descriptor is placed inside the user tag, then the tool input does not control it, and any user edited or changed code was put in its place upon document regeneration. So in this conventional scenario, a decision was made in advance about what could be changed by a user and what content could be changed by the tool. Further, user tags were guarding the user code 706, 708, and the number of user tags must remain constant since they are tool controlled. Thus, tags could not be added by a user, since upon regenerations, the tool using the tool input, would not “know” what to do with user generated tags since there was a tool input controlled one-to-one relationship between tags in the tool input to tags in the base document. Users could only type within the user tags, and the tool would pull this user code into the base document, verbatim, between the tags as organized and controlled by the tool input. Each user tag was unique and it had to directly match the location in the tool input. The user had no ability to name a tag and add extra information. Tool inputs typically had extra tags which were often not required by the users, for example, tags for extra class information, tags for extra file information, and other tags where a user may want to insert user code. Upon regeneration, any user edits outside the tags were just ignored, because the tool didn't know where to place the code upon regeneration.
This is a general computer problem that is encountered many times over and over because there are many tools that begin with a tool input, fill in some information, and then generate a document. This method works fine when you just create the document once, but the problem occurs when you later attempt to regenerate the document with two points of modification, one at the tool input, and the other the edited document. Again, the first conventional solution just prohibits regeneration of the document (i.e., round-tripping). The other conventional solution allows round-tripping, but limits user freedom by pulling in only code within user tags.
The tool inputs can be created by anyone not excluding the tool creator or users. However, in many document environments this becomes a problem because tool inputs need to remain general in nature, while iterations of development become more specific. In order to control a document environment (e.g., office documents, test development programs, or program development), the tool input and/or tool can often only be changed by an authorized party. Consider as an example, that another method is added to the tool input that a test-template creator wants everyone to use. This is a way for an authorized party to provide or require a new method, for test-developers to use. Since a tool input is general in nature, users developing a specific iteration should not be allowed to alter a generalized tool input.
When a tool is changed, the resulting generated output is changed. Any documents generated by the tool before the tool changed will need to be regenerated in order to incorporate the changes. Further, when the document is regenerated with the changed tool, a user may need to edit or add content in order to complete the user customization portion of the changes. For example, if a new method signature is forced by the tool into a portion of the generated document, then the user may need to write code for the new method. Documents are often regenerated to introduce new content and configuration when a program or a program test is under development. For the same reasons, when the tool inputs are changed to include new content, the documents need to be regenerated to incorporate these changes. For example, in developing test cases, a tool input is used to expose additional methods to test developers. So when changes are made to the underlying framework that functionality is exposed to test developers through a changed tool input. The conventional round-trip-user-tag method is unable to handle simultaneous changes from multiple sources.
Changes made to a tool input are generally changes that are general in nature and will apply across many documents. Changes made to how a tool generates a document or a specific document's content are often more specific and related to a specific document being generated. However, changes made to a tool can also be general in nature and changes made to a tool can also be a new version of the tool (e.g., version 1.0 becomes version 1.2) Changes made to a tool may generate a series of menus that need to be responded to and may involve user interaction during regeneration. Changes made to tool inputs and tools are known and require significant user interaction (i.e., cutting and pasting); no system has been developed to remove these inefficiencies.
For example, in the conventional round-trip-user-tag solution a tool may have changed a parameter 616 in a method (possibly through user interaction) during configuration. In a subsequent regeneration 510, since this tool change created a signature 616 not recognizable in the tool input, a subsequent regeneration 510, of the tool generated document with user tags 506, would include a copy of both methods. The user then needed to cut and paste to return to a desired state.
The present technology is directed towards providing a change management method and system for tool-based document regeneration which incorporates tool input changes, tool changes, and user changes during iterative document creation without the use of user-tags. After a tool-based document is generated and saved by a tool, and then edited by a user, during a next iteration of creating the edited document, the tool first generates a new base document. The base document is then saved, and a three way merge is performed on the former iteration's base document, this iteration's new base document, and the former iteration's edited document. The former iteration's base document serves as the base of the merge process. The merge outputs a merged document, and when further edits are needed, the merged document is edited and saved as the edited document. If no edits are necessary, the merged document is saved directly as the edited document. In another respect, in each iteration a new base document and an edited document are saved for a possible next iteration.
Additional features and advantages will be made apparent from the following detailed description of the illustrated embodiment which proceeds with reference to the accompanying drawings.